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REMARKS 

This responds to the Office Action mailed on February 28, 2007 . 
Claims 1,-4, 6, 10, 13 and 26 are amended, claims 20, 22 and 25 are canceled, and no 
claims are added; as a result, claims 1-19, 21, 23-24 and 26 are now pending in this application. 

§102 Rejection of the Claims 

Claims 1-19, 21, 23-24 and 26 were rejected under 35 U.S.C. § 102(b) for anticipation by 
Perkowski (U.S. 5,950,173). 

Applicants respectfully submit that claims 1-19, 21, 23-24 and 26 should not be rejected 
under 35 U.S.C. § 102(b) for the reason that Perkowski does not disclose each and every 
limitation of the claim 10, as amended, of their present application. 

To anticipate a claim, the reference must teach every element of the claim. 

"A claim is anticipated only if each and every element as set forth in the claim is found, 
either expressly or inherently described, in a single prior art reference." 

Claim 10 includes the following limitations: 

gathering product information from diverse external sources; 

...the gathered product information including a first attribute-value pair that includes a 
first attribute and a first value; ... 

....translating the first attribute to a second attribute responsive to identifying the first 
attribute in a list that includes a plurality of attributes that are associated with the second 
attribute, the second attribute being a canonical representation of the plurality of 
attributes respectively. 

The Final Office Action highlights the following in Perkowski: 

Registering Consumer Products With The IPI Finding and Serving Subsystem 

The utility of the product finding functionalities of the system of the present invention 
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depends in large part of the number of consumer-products registered with the IPI Finding 
and Serving Subsystem thereof. In principle, numerous techniques may be employed 
separately and in combination with each other in order to construct the IPI and Non-IP I 
Registrant Databases supported by the IPD Servers of the present invention. Five such 
tecnhiques will be detailed below. 

According to a first database construction technique, the administrator of the IPI 
Registrant Database would transmit Product Registration Requests (PRRs) in the form of 
electronic documents to each and every the manufacturer having been issued, for 
example, a six digit UPC Manufacturer Identification Number (MIN) by the UCC, Inc. 
Such electronic documents can be transmitted using conventional MIME protocols such 
as, for example, STMP. The Product Registration Request document would seek to 
ascertain from the manufacturers the various information items (including the menu of 
URLs) identified in the IPI Registrant Database of FIG. 4A1. In response to the Product 
Registration Request, each solicited manufacturer would send back to the administrator 
of the IPI Registrant Database (for each of its consumer products) its UPC number and a 
menu of URLs indicating the location of the information resources identified in the 
Product Registration Request document. This information can then be used to readily 
construct the IPI Registrant Database of the illustrative embodiment. 

According to a second database construction technique, a global advertising campaign 
would be launched (over various media) in order to solicit the various information 
elements identified in the IPI Registrant Database of FIG. 4A1 and thus register the 
products of the manufacturers selling UPC-labelled products. Preferably, such 
information would be collected by way of an electronic document transfer subsystem set- 
up to cooperate with the system of the present invention in order to facilitate database 
construction operations. 

According to a third database construction technique, the IPI system itself would 
continuously solicit consumer product registrations over time in order to collect 
information from companies responding favorably to the solicitations. While such 
solicitation efforts can involve the issuance of product registration requests using various 
types of media, it is preferred that the information collection operations are carried out 
using electronic document transfer techniques described hereinabove. 

According to a fourth database construction technique, a number of commercial on-line 
Internet search engines, such as Altavista.TM., Yahoo.TM., WebCrawler.TM., 
Lycos.TM., Excite.TM., as well as powerful off-line parallel-processing processing 
search engines, would be enlisted to analyze (i.e. mine) information on the World Wide 
Web in order to collect and link the information elements specified in the IPI Registrant 
Database of FIG. 4A1. 



Once an "initial" IPI Registrant Database has been constructed using any one or more of 
the four database construction techniques described hereinabove, manufacturers 
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registered therewith can be periodically contacted using Web-based electronic document 
(i.e. message) transfer techniques in order to request updating and confirmation of the 
UPC/URL listings contained within the database of the IPI subsystem of the present 
invention. 

Perkowski, Col. 24, line 57 - Col. 25, line 54. 

The above quote from Perkowski describes the registration of products in an Internet 
Product-Information (IPI) (Col. 6, line 4) subsystem. Specifically, the above quote from 
Perkowski describes four database construction techniques that may be used to register products 
in an IPI registrant database (Figure 4A1). 

According to the first database construction technique, the administrator of the IPI 
Registrant Database sends a Product Registration Request to a manufacturer. In response, the 
manufacturer sends back a list of products. Each product in the list is identified by a Universal 
Product Number (UPC) (Abstract) and a list of URLs that are used to construct the IPI Registrant 
Database. 

According to the second database construction technique, the administrator of the IPI 
Registrant Database presumably uses an advertisement campaign to solicit information elements 
in the IPI Registrant Database "and thus register the products of the manufacturers selling UPC- 
labeled products" (Col. 25, line 25). 

According to a third database construction technique, the IPI System solicits product 
registrations from companies. 

According to a fourth database construction technique, an on-line Internet search engine 
(e.g., Yahoo™) analyzes information on the World Wide Web in order to collect and link 
information in the LPI Registrant Database (Figure 4A1). 

Claim 10 requires gathering product information including a first attribute-value pair that 
includes a first attribute and translating the first attribute to a second attribute responsive to 
identifying the first attribute in a list that includes a plurality of attributes that are associated with 
the second attribute, the second attribute being a canonical representation of the plurality of 
attributes respectively. For example, in one example use scenario, product information that is 
gathered may include a first attribute-value pair, "screen_size = xga." Continuing with the 
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example, the attribute "screen_size" may be translated to a second attribute, "display res," 
responsive to identifying "screen_size" in a list that includes multiple attributes (e.g., 
"screen_size", "Screen Size", "display res", etc.), the second attribute, "display res" being a 
canonical representation of the respective multiple attributes (e.g., "screen_size", "Screen Size", 
"displayres", etc.) (Application, pages 14 - 16). 

The above quote from Perkowski describes subject matter that fails to anticipate the 
elements of the limitations of the claim 10 for the following reasons. 

First, the above quote from Perkowski fails to describe gathering an attribute-value pair. 
For example, the first quote from Perkowski describes receiving a list that includes a product that 
is identified by a Universal Product Number (UPC). Receiving a list of UPCs is not gathering an 
attribute- value pair. The second quote describes the solicitation of information elements in the 
IPI Registrant Database. Information elements in the IPI Registrant Database are not attribute- 
value pair(s), as described below. The third quote describes the solicitation of product 
registrations without providing any description of the product registrations provided in response 
to the solicitation and before such product registrations are stored in the table 4A1. Finally, the 
fourth quote describes the collection of information in the IPI registrant database without 
providing any description of the information collected before such information is stored in the 
table 4A1. To the point, a product registration or information that is stored in a table provides 
insufficient information about the product registration or information as it is communicated and 
before it is stored in a table. Indeed, communication of the UPC as disclosed by Perkowski may 
obviate the gathering of attribute- value pairs, as required by the claim 10, because the UPC may 
implicitly define the attributes of the product identified by the UPC. 

Second, the above quote from Perkowski cannot possibly describe a translation of an 
attribute, much less the translation of an attribute to a canonical representation of the attribute 
because, as noted above, Perkowski fails to describe an attribute-value pair and the attribute- 
value pair, as required by the claim 10, includes the attribute that is to be translated. 

The Final Office Action states the following: 



For products that are already in the database, col. 25, lines 47-54 describe a procedure 
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where product information, such as the URL, can be updated. FIG. 4A2 illustrates a 
column (third from left) where the updated URL information is held. A second column 
(first from left) has the original URL. Accordingly, FIG. 4A2 establishes a representation 
of data (a table) that includes new attribute information (updated URL) related to an alias 
(original URL). This relationship between the updated URL and original URL can be 
defined as an attribute value paring. The registrant's name can be a second attribute. The 
second attribute is a canonical representation of the other attributes in the sense that it is 
an alternative representation associated with the other attributes and is made in 
accordance with a canon (a relation, such as a relational table). 

Final Office Action, Page 6. 



Applicants submit that the above quote from the Final Office Action fails to appreciate 

the meaning of the term "attribute" in the context of a table as described by the application and 

as understood by those having ordinary skill in the art of databases. The present application 

provides the following example: 

In an implementation of a relational database, a relation corresponds to a table having 
rows, where each row corresponds to a tuple, and columns, where each column 
corresponds to an attribute. From a practical standpoint, rows represent records of related 
data and columns identify 10 individual data elements. A table defining a retailer's 
product line may, for example, have product names, product numbers (e.g., Stock 
Keeping Units or SKUs), prices and other product features. Each row of this table holds 
data for a single product and each column holds a single 15 attribute, such as a product 
name. 



Application, Page 4, lines 5-35 



The Wikipedia webpage for "database" states the following: 

The products that are generally referred to as relational databases in fact implement a 
model that is only an approximation to the mathematical model defined by Codd. Three 
key terms are used extensively in relational database models: relations, attributes, and 
domains. A relation is a table with columns and rows. The named columns of the relation 
are called attributes, and the domain is the set of values the attributes are allowed to take. 



Wikipedia, http : //en . wi kipedia.org/wiki/Database (April 6, 2007). 
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According to the above quote from the application and according to the Wikipedia entry 
for "database", the "updated URL" in the table illustrated in Figure 4A1 is not an attribute. 
Moreover, if the "updated URL" is not an attribute, then relationship between the "updated 
URL" and the original URL cannot possibly be an "attribute->value" pairing. Most importantly 
and as previously stated, information that is stored in a table is insufficient to describe the 
information as it is communicated and before it is stored in the table. Indeed, communication of a 
UPC, as disclosed by Perkowski, may obviate the gathering of attribute-value pairs, as required 
by the claim 10, because the UPC may implicitly define the attributes of a product identified by 
the UPC. 

The Final Office Action also states that the independent claims do not elaborate on the 
nature of the translation. Applicants respectfully disagree. Claim 10 requires: 

....translating the first attribute to a second attribute responsive to identifying the first 
attribute in a list that includes a plurality of attributes that are associated with the second 
attribute, the second attribute being a canonical representation of the plurality of 
attributes respectively. 

Accordingly, claim 10 requires two attributes, a first attribute and a second attribute. 
Claim 10 further requires the second attribute to be a canonical representation of a list of 
attributes that includes the first attribute. Finally, claim 10 requires the translation of the first 
attribute to the second attribute responsive to the first attribute being identified in the list of 
attributes. Applicants submit that the independent claims go beyond an elaboration on the nature 
of the translation and explicitly recite the elements and method of the translation. 

In summary Perkowski cannot be said to anticipate the above quoted limitations because 
Perkowski fails to describe an attribute- value pair and claim 10 requires the gathering of an 
attribute value pair that includes a first attribute and the translating of the first attribute to a 
second attribute responsive to identifying the first attribute in a list that includes multiple 
attributes. 

In summary, Perkowski does not disclose each and every limitation of claim 10, as 
required to support a rejection of this claim under 35 U.S.C. § 102(e). 
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The above remarks are also applicable to a consideration of independent claims 1, 12, 23, 
24, and 26. Applicants request that the above remarks and amendments contained herein also be 
considered when examining independent claims 1, 12, 23, 24 and 26 for allowability. 

Claims 2-9 depend on independent claim 1. Claim 1 1 depends on independent claim 10. 
Claims 13-19 and 21 depend on independent claim 12. Claim 25 depends on independent claim 
24. As dependent claims are deemed to include all limitation of claims from which they depend, 
the rejection of claims 2-9, 11, 13-19 and 21 under 35 U.S.C. § 102 is also addressed by the 
above remarks, and the amendments contained herein. 
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CONCLUSION 

Applicants respectfully submit that the claims are in condition for allowance and 
notification to that effect is earnestly requested. The Examiner is invited to telephone 
Applicants' attorney at 408-278-4046 to facilitate prosecution of this application. 

If necessary, please charge any additional fees or credit overpayment to Deposit Account 
No. 19-0743. 

Reservation of Rights 

In the interest of clarity and brevity, Applicant may not have addressed every assertion 
made in the Office Action. Applicant's silence regarding any such assertion does not constitute 
any admission or acquiescence. Applicant reserves all rights not exercised in connection with 
this response, such as the right to challenge or rebut any tacit or explicit characterization of any 
reference or of any of the present claims, the right to challenge or rebut any asserted factual or 
legal basis of any of the rejections, the right to swear behind any cited reference such as provided 
under 37 C.F.R. § 1.131 or otherwise, or the right to assert co-ownership of any cited reference. 
Applicant does not admit that any of the cited references or any other references of record are 
relevant to the present claims, or that they constitute prior art. To the extent that any rejection or 
assertion is based upon the Examiner's personal knowledge, rather than any objective evidence 
of record as manifested by a cited prior art reference, Applicant timely objects to such reliance 
on Official Notice, and reserves all rights to request that the Examiner provide a reference or 
affidavit in support of such assertion, as required by MPEP § 2144.03. Applicant reserves all 
rights to pursue any cancelled claims in a subsequent patent application claiming the benefit of 
priority of the present patent application, and to request rejoinder of any withdrawn claim, as 
required by MPEP § 821.04. 
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